Subject: Explorer FSMs and Netbios

From: [email-masked] (Paul Brittain)
Date: Mon, 8 Aug 94 12:09:01 BST

Lakshman,

Thanks for your prompt response to my mail last week.

Firstly, my apologies for having confused the source of the FSMs I referenced
in my previous mail.  A missing page in my hard-copy had placed a mail header
from Pandian above the FSMs you had posted, thus leading to some confusion over
which FSMs were which.

Turning to the specific points you raised:

>Well i have done an exhaustive rework on the FSM and sent to the group
>last week which covers both the explorer and regular messages. Please
>read that fsm and don't try to reinvent the wheel. If there are any
>glaring problems to that fsm we can corret them. I must confess i am not an
>expert in netbios exchange, but i think the fsm that i provided will
>solve, if not we can correct that fsm.
>

Your FSMs certainly form a good basis on which to merge the explorer traffic
into the main FSM.  I had some difficulty trying to follow all the *_ex
traffic to see how the explorer frames were being handled, though your FSM is a
considerable improvement on the current document.

This indicates that the main point we need to resolve is whether standard DLSw
switches ever issue NQ_cs messages, as per my first point in the last post.  If
not, then the explorer traffic should be separable.  We may choose not to make
this split in the spec, but if this is not readily achievable then we probably
have a bugged FSM for the explorer traffic.

PLEASE can people post their opinions on whether the design goal is to have
NetBIOS always use NQ_ex/NR_ex/CUR_cs, or can it sometimes use NQ_cs/NR_cs
instead?

(Note that NQ_cs/NR_cs messages could still be received from pre-standard DLSw
implementations even if we never issue NQ_cs messages, but this one special
case is easily handled if we resolve the main issue first.)

>>PJB>* The CANUREACH_cs is a circuit setup message.  There should only be one
>>PJB>* such message received by any one target DLSw since the CANUREACH_ex
>>PJB>* exchange identifies the correct DLS partner.  Hence there is no need to
>
>I think an implementation can have, thru management, static entries on where
>the remote parnters are located. In this case there is no need to send
>canureach_ex messages instead can send canureach_cs directly. In this case
>maybe we need to update the list?

I'm not sure I have understood your response, so I'll explain what I meant in
more detail to see if that resolves the issue.

If we look back at the section of the spec in question:

   Upon the receipt of a DLC_DL_STARTED signal in the RESOLVE_PENDING state, the
   Data Link Switch may update its topology table base upon the remote MAC address
   information.  The ICANREACH message should be returned to all Data Link
   Switches that had sent a CANUREACH message....

I don't think that static configuration should affect whether a DLSw should be
REQUIRED to maintain a list of ALL remote switches that sent it a CUR_cs for a
new circuit.  There should only be one however the route was determined before
the CUR_cs was sent.

An alternativce way of looking at it is that in previous discussions on RFC
1434 we had said that a DLSw implementation may choose to respond to only the
first CUR received for a circuit.  Surely this still holds for CUR_cs in the
new standard, thus eliminating the requirement for a list of partners that sent
the CUR_cs?  If not, we should define how the DLSw is supposed to choose
between the many ICR_cs messages it is likely to receive for this one circuit.

(Note that the list of DLSw partners that have sent a CUR_cs for a new circuit
that is in the process of starting up should not be confused with the MAC cache
table.  The latter could, clearly, be updated on the basis of all CUR messages
received regardless of whether they start a new circuit or not)

Just to complicate matters, the route determination implicit in explorer frames
would benefit from requiring a reply to all CUR_ex messages.  However these
frames are not attempting to set up a circuit, hence this should require
less resource than trying to support multiple CUR_cs messages.

       ---------------------------------------------------------------

Yours,

Paul Brittain
Data Connection Limited